The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.
Present day keyboard, video and mouse (KVM) appliances and baseband management controllers (BMCs) allow a user to access remote servers and other devices by passing the keyboard, video and mouse signals between the user's device (typically a laptop, PC, tablet, smartphone, etc.) and the KVM appliance or BMC. For the purpose of discussion, the following examples will make reference only to a KVM appliance, but it will be appreciated that they are equally applicable to communication with a BMC.
The keyboard and mouse signals received by the KVM appliance are typically received in some network protocol, for example Ethernet protocol packets, and then converted to a format (e.g., USB) that the remote device can accept. Video from the remote device can be received by an intermediate dongle, converted into a network protocol (e.g., Ethernet protocol) and then passed on to the KVM appliance. The KVM appliance may then pass on the video to the user's device.
When video is compressed within the KVM appliance using a certain type of compression engine, it must be decompressed after being received by the user's browser using the same type of decompression engine. There currently are a number of different video compression protocols being used by various manufacturers. For example, Dambrackas Video Compression (DVC) is a proprietary video compression scheme of Avocent, Inc., which is a company of Emerson Network Power. Another well known compression scheme is JPEG. Still another is “Run Length Encoding” (“RLE”). It will be appreciated by those skilled in this art that various other compression protocols exist as well. In a data center, for example, one video server may serve up video content encoded with DVC while another video server uses JPEG to encode the video file content that it serves up. And still another video server may use RLE to encode the video file content that it serves up.
Previously implemented KVM appliances and BMCs were typically limited to serving up video using only a single video compression scheme. Accordingly, to accommodate multiple video compression schemes, multiple KVM clients would typically have been required. Fox example, this would have required multiple KVM appliances to be used, with each KVM appliance having one or more servers that each make use of a different compression engine. This would have required additional storage space and configuration information to be stored on the web server of a KVM appliance, which would also add development costs and additional maintenance costs.
With the recent development of HTML5, the ability to create and communicate via multiple “web sockets”, outside of the HTTP connection, which can each form distinct communication paths, now exists. It will be appreciated that the WebSocket protocol provides bi-directional, full-duplex communication channels over a single TCP connection. It is implemented in both web browsers and web servers, although it may be used by any client or server application. It makes possible more enhanced interaction between a browser and a web site by providing a standardized way for a server to send content to the browser without being solicited by the client, and allowing for messages to be passed back and forth while keeping the connection open between the browser and the server. This allows bi-directional, ongoing communications to take place between a browser and the server without the polling that would otherwise be required using previously developed HTML protocols. Currently HTML5 is supported by several web browsers including Apple Corporation's SAFARI® web browser, Mozilla's FIREFOX® web browser, the Google CHROME® web browser, and INTERNET EXPLORER® version 10 from Microsoft Corp.
Another advantage of an HTML5 client is that it does not require any installation on a user's browser. This is because everything the web browser needs is downloaded at the time of execution (i.e., when the HTML5 client code is first served up to the browser). The challenge has been how to take advantage of this capability to provide a more robust KVM vMedia client that is able to deliver video that needs to be decoded using multiple different types of video decompression, via a single KVM vMedia client.